前幾天把 Git 和專案規格整理好之後，接下來就是正式開發。

Day 04 我們讓 Claude Code 裝好了 Godot。那時候只確認了一件事：版本號印得出來。
今天要把它真正接上開發流程。不過很快我就遇到一個問題：

AI 寫完一段程式碼，怎麼讓它自己驗證，不用再問我？

如果每次都要我自己開 Godot、按 F5，再把錯誤訊息貼回去，後面的開發流程就會一直卡在這裡。

問題情境：AI 沒有取得螢幕權限

在我這次的設定裡，我沒有給予 Claude Code 使用 macOS 螢幕與視窗的存取權限，主要是有一些自己的考量。

所以它雖然能讀我的檔案、寫程式碼、執行 Terminal 指令，卻看不到我開著的 Godot 遊戲畫面。

因此，在把 Godot 接進 CLI 驗證流程之前，每一次驗證大概都長這樣：

Claude Code 寫完 CardDatabase.gd
  ↓
「請你開 Godot 按 F5 看看有沒有錯」
  ↓
你切到 Godot、等它載入、按 F5、看到一行紅字
  ↓
你把錯誤訊息複製、切回編輯器、貼上
  ↓
Claude Code 讀到錯誤，修好，然後說「請你再試一次」
  ↓
（回到第二步）

每一輪都要經過你轉述。

AI 寫程式碼很快，但整個流程還是會卡在人身上，而且卡在最無聊的那一段：幫 AI 轉述錯誤訊息。

而且麻煩的是，轉述可能會失真。
你只複製了那一行紅字，但真正有用的線索，可能就在它上面三行。
所以我開始想：

能不能讓 Claude Code 自己執行 Godot，然後自己看到錯誤？

答案就是今天要用到的兩種方式：
godot -e 和 godot --headless。

一次安裝，同一個 Godot

Day 04 那行指令是：

brew install --cask godot

當時只把它當成「裝一個遊戲引擎」。

但看一下它到底裝了什麼：

$ which godot

/opt/homebrew/bin/godot

$ ls -l /opt/homebrew/bin/godot

/opt/homebrew/bin/godot -> /Applications/Godot.app/Contents/MacOS/Godot

/opt/homebrew/bin/godot 是一個 symlink（符號連結），指向 Godot.app 裡面的執行檔。

換句話說：

Godot.app 和終端機裡的 godot，其實是同一個程式。

從 Finder 打開它，可以使用圖形介面；從 Terminal 呼叫它，則可以使用命令列。

先確認它確實可以執行：

$ godot --version

4.7.1.stable.official.a13da4feb

💡 這件事不是 Godot 獨有的。

很多桌面應用程式的執行檔本身就支援命令列參數，只是平常不一定會用到。

裝好一個工具之後花一點時間看看它的 --help，有時候會發現原本以為只能手動做的事情，其實早就有命令列可以使用。

給人用指令：godot -e

在專案目錄下輸入：

godot -e

Godot 編輯器會直接帶著這個專案打開。

比起：

「開 Spotlight → 搜尋 Godot → 等專案管理器 → 點 Import → 瀏覽資料夾 → 選 project.godot → Import & Edit」

這一行可以省掉好幾個步驟。

-e 是 --editor 的縮寫。

之後我每天都會用這個指令直接開啟目前的 Godot 專案。

給 AI 用指令：--headless

headless 直譯是「無頭」，在這裡指的是不使用圖形介面。

一個沒有視窗的遊戲引擎聽起來很沒用，畢竟遊戲就是要看的。

但它剛好符合 AI 的工作方式：

關鍵在第一列。

有視窗的時候，很多結果會出現在畫面上；headless 模式下，程式執行時產生的訊息會出現在 Terminal，而文字是 AI 可以讀取的。

最基本的一個指令：

godot --headless --import

它會在沒有開啟遊戲視窗的情況下處理專案資源，完成後退出。

不開視窗，也不需要你按任何鍵。

這一步很重要，因為它讓 Godot 實際讀取專案裡的設定與資源。原本藏在檔案裡的一些問題，也有機會在這裡直接看到。

我故意把專案弄壞

光知道指令可以執行還不夠，我想直接測試：

如果專案真的有問題，Claude Code 能不能自己發現？

所以我故意修改 project.godot，把主要場景改成一個不存在的檔案：

run/main_scene="res://scenes/MainMenu.tscn"

但實際上專案裡沒有 MainMenu.tscn。

接著執行：

$ godot --headless --quit-after 10

Terminal 直接出現：

ERROR: Cannot open file 'res://scenes/MainMenu.tscn'.
ERROR: Failed loading resource: res://scenes/MainMenu.tscn.
ERROR: Failed loading scene: res://scenes/MainMenu.tscn.

三行。檔名完整，原因也很明確。
這種錯誤就很適合交給 Claude Code 處理。

它不需要我截圖，也不需要我複製貼上錯誤訊息，因為錯誤本身就已經出現在它可以讀取的 Terminal 裡。

流程開始改變

原本的流程：

Claude Code 寫完程式
  ↓
你開 Godot
  ↓
你按 F5
  ↓
你看到錯誤
  ↓
你複製錯誤
  ↓
貼回 Claude Code
  ↓
Claude Code 修正
  ↓
你再按一次 F5

現在可以變成：

Claude Code 寫完 CardDatabase.gd
  ↓
Claude Code 自己跑 godot --headless --import
  ↓
Claude Code 自己看到錯誤，自己修，自己再跑一次
  ↓
確認通過，才回報給你

你從這個迴圈裡消失了。

這不是說之後都不用開 Godot。

而是原本需要人手動完成的「執行 → 看錯誤 → 回報」，有一部分可以交給 AI 自己完成。

它表面上是在講 CLI，實際上改變的是整條開發流程。

但 headless 也有做不到的事情

headless 能確認程式能不能正常執行，卻不能告訴你遊戲畫面好不好看。

例如：

我後來就真的遇到過這種情況。

有一次重新套上美術素材之後，畫面排版連續出現問題，上方和下方的元件被切掉。
但 --headless 跑起來完全正常。
因為從程式的角度來看，它確實沒有壞。
這個問題後來會在 Day 21 再詳細記錄。
所以現在的分工很清楚：

兩種方式都要用，只是用在不同的問題上。

今天的筆記

今天實際用下來，我記住幾個指令：

1. godot -e：直接開啟目前的 Godot 專案編輯器。
2. godot --headless：不開圖形介面，讓 AI 可以透過 Terminal 執行 Godot。
3. --quit-after N：讓程式執行指定數量的 frame 後自動退出。
4. headless 可以幫忙確認「有沒有炸」，但不能取代人看畫面。

Day 01 說過這個系列的心法是：

攔截、追問、親手重做。

今天這篇比較特別，它不是攔截 AI 要做的事，而是給 AI 一雙眼睛。

明天 Day 09，我們把驗證再往前推一步：
有一行指令，可以在完全不執行遊戲的情況下檢查語法。
但它藏了兩個坑：
一個假裝永遠通過，另一個天天誤報。

💬 你有沒有裝了某個工具很久，後來才發現它其實有命令列介面？歡迎留言聊聊。